بدايه مبرمج

بدايه مبرمج

Photo

⚡SOLID Principles⚡

⚡ خامس مبدأ(DIP) Dependency Inversion Principle

“ High level modules should not depend upon low level modules. Both should depend upon abstractions”

الـ High level classes يجب ألا تكون مُعتمدة على low level classes و يجب ان يكون بينهما وسيط وهو abstractions.

على سبيل المثال افترض عندك كلاس سوبر ماركت وعشان تملي السوبر ماركت بالأصناف لابد انه تستخدم كلاسات كُل صنف مثلاً كلاس خضروات وكلاس الفواكه وتستدعي دالة الإضافة.

Fruit f = new Fruit();
f.add();
Vegetable v = new Vegetable();
v.add();

ونفس الشيء في بقية الأصناف ..

هنا كلاس السوبر ماركت يُعتبر ( High level ) مُعتمد بشكل كُلي على كلاسات الأصناف ( low level )،بمعنى أي تغيرات في ( low level ) لابد ان تنعكس في ( High level ) طيب ايش المشكلة اللي ممكن تصير🙄!

تخيل لو كلاس الفواكه عدل في دالة إضافة فاكهة ❗ هنا انت مضطر ترجع تعدل في كلاس السوبر ماركت.

وبكذا خالفنا مبدأ Open Close واصبح كلاس السوبر ماركت مفتوح للتعديلات😵وايضاً مُعتمد على كلاسات أخرى أي خالفنا مبدأ DIP .

طيب والحل ،السوبرماركت ضروري نضيف لها اصناف🤔❗

الحل هو عمل وسيط عن طريقه تضيف الصنف اللي تحتاجه وبدون ما تعتمد على الغير 😉 .

لنفرض الوسيط هو Interface يكون بداخلها دالة الإضافة، ومن ثم نجعل كلاسات الـ low level تعمل Implement لهذا الوسيط .

بحيث يستطيع كلاس السوبر ماركت التعامل مع low level عن طريق الوسيط .

وبكذا طبقنا المبدأ واصبح كلاس السوبر ماركت منعزل تماماً عن التغيرات اللي ممكن تحدث في كلاسات Low Level أي جعلنا الكلاس مُغلق عن أي تعديلات وبنفس الوقت غير مُعتمد على أي كلاس، أيضاً قللنا من Coupling واقصد بالـ Coupling هو ترابط الكود .

ملاحظة : عند زيادة Coupling في الكود يصبح صعب التعديل عليه او تطويره لذلك تسعى SOLID إلى تقليل من Coupling وزيادة Cohesion.

⚡أخيراً
هذه المبادئ يوجد بينهما علاقة بمعنى لو اخذت كُل منهم بشكل معزول عن الآخر وطبقته فسوف تحصل على فائدة ولكن ليست كبيرة.

تمنياتي لكم بالتوفيق 🙏❤

www.tg-me.com/in/بدايه مبرمج/com.beginprogrammer/643

1.9K viewsOct 24, 2021 at 02:09

⚡SOLID Principles⚡

⚡ خامس مبدأ(DIP) Dependency Inversion Principle

“ High level modules should not depend upon low level modules. Both should depend upon abstractions”

الـ High level classes يجب ألا تكون مُعتمدة على low level classes و يجب ان يكون بينهما وسيط وهو abstractions.

على سبيل المثال افترض عندك كلاس سوبر ماركت وعشان تملي السوبر ماركت بالأصناف لابد انه تستخدم كلاسات كُل صنف مثلاً كلاس خضروات وكلاس الفواكه وتستدعي دالة الإضافة.

Fruit f = new Fruit();
f.add();
Vegetable v = new Vegetable();
v.add();

ونفس الشيء في بقية الأصناف ..

هنا كلاس السوبر ماركت يُعتبر ( High level ) مُعتمد بشكل كُلي على كلاسات الأصناف ( low level )،بمعنى أي تغيرات في ( low level ) لابد ان تنعكس في ( High level ) طيب ايش المشكلة اللي ممكن تصير🙄!

تخيل لو كلاس الفواكه عدل في دالة إضافة فاكهة ❗ هنا انت مضطر ترجع تعدل في كلاس السوبر ماركت.

وبكذا خالفنا مبدأ Open Close واصبح كلاس السوبر ماركت مفتوح للتعديلات😵وايضاً مُعتمد على كلاسات أخرى أي خالفنا مبدأ DIP .

طيب والحل ،السوبرماركت ضروري نضيف لها اصناف🤔❗

الحل هو عمل وسيط عن طريقه تضيف الصنف اللي تحتاجه وبدون ما تعتمد على الغير 😉 .

لنفرض الوسيط هو Interface يكون بداخلها دالة الإضافة، ومن ثم نجعل كلاسات الـ low level تعمل Implement لهذا الوسيط .

بحيث يستطيع كلاس السوبر ماركت التعامل مع low level عن طريق الوسيط .

وبكذا طبقنا المبدأ واصبح كلاس السوبر ماركت منعزل تماماً عن التغيرات اللي ممكن تحدث في كلاسات Low Level أي جعلنا الكلاس مُغلق عن أي تعديلات وبنفس الوقت غير مُعتمد على أي كلاس، أيضاً قللنا من Coupling واقصد بالـ Coupling هو ترابط الكود .

ملاحظة : عند زيادة Coupling في الكود يصبح صعب التعديل عليه او تطويره لذلك تسعى SOLID إلى تقليل من Coupling وزيادة Cohesion.

⚡أخيراً
هذه المبادئ يوجد بينهما علاقة بمعنى لو اخذت كُل منهم بشكل معزول عن الآخر وطبقته فسوف تحصل على فائدة ولكن ليست كبيرة.

تمنياتي لكم بالتوفيق 🙏❤

BY بدايه مبرمج